IaC 目的・メリット・デメリットをちゃんと理解する
IaCを利用することで得られる効果をちゃんと理解できてない。
このままIaCの利用を続けると、IaCを使うべき時に使わなかったり、あまり効果の出ない状況で使ってしまったりする。
そんな状態とはおさらばするために、今一度IaCとは何か、どんなメリデメがあるのかを正確に把握しておく。
手段を勉強するときは、絶対に手段から得られるメリデメも一緒に暗記しておく。
IaCを使うことで得られる効果
hr.icon
IaCを利用することで得られる効果はいくつかあり、都度どのメリットを享受したいかを抑えておくといい。
得られる効果と自分たちの要求を比べることで、IaCを導入するかを判断しやすくなる。
自分たちのシステムではあまりメリット得られないなぁとなるなら、IaCを無理に導入しなくてもいい。
また、全てをIaC化しなくてもいい。システムの一部だけでも効果を得られるなら、それを試してみると良き。
効果1：環境ドリフトを防げる
システムを本番環境のみで稼働させるのは、PoCでもない限りほとんどないと思う。
インフラを作るときも本番環境以外に、検証用環境、開発用環境などを作るのが一般的。
検証用環境がないと本番にいきなり変更を加えることになり、バグ・障害が発生するリスクが増える。
開発用環境が無いと、気楽に技術検証したりリソースを構成を試してみたりということができなくなる。
このとき大事なのが、本番と検証のシステムを同じ状態にしておくということ。
本番環境と検証環境のシステムの内容が異なる状態を「環境ドリフト」という。
「環境ドリフト」が起きてしまうと、検証環境で変更のテストをして成功したとしても、本番環境では障害が起きる恐れがある。
手動時代は、ミスや忘れによって環境ドリフトがよく起こっていたとか。
インフラをIaCで作ることで、環境に問わず同じ構成を作ることができ、環境ドリフトが起きるのを簡単に防ぐことができるようになった。
memo.icon
環境ドリフトが懸念されるのは、バグ・障害が起きやすいから。
この環境ドリフトがあると以下のようなデメリットが生まれる。
変更したくない気持ちが生まれたり
環境ドリフトを解消するために時間を取られたり
障害発生による対応時間を取られたり
ただ、環境ドリフトを起こさないために無理にIaCを導入する必要もない。
環境ドリフトが起きてても、システム障害が発生しないようなリソースだったりするなら無視してもいい。
無理にIaCに入れ込もうとして複雑になるくらいなら無視。
効果2：インフラの構成内容の理解・調査にかかる時間を短縮する
コードの内容を見るだけで、このインフラがどういう構成を組んでるのかが分かると、めちゃくちゃ時間短縮になる。「環境にあるリソースのどれが本システムのインフラに含まれてる？」とかから調べる手間が減るのめっちゃいい。
把握漏れのリスクも減る・無くなるので、そこもポイント高い。
これは特に、管理者・運用者が変わった時に特に効いてくる。
同じシステムを同じ管理者・運用者がずっと見守ることはほぼない。
転職や部署移動などで管理者・運用者は変わるのが必然。
新しい管理者・運用者はいち早くインフラの内容を理解しないといけない。
その場合、コードが残ってる状況と残ってない状況、どっちが楽かというと残ってる状況の方が断然楽。
インフラを構成してるリソース・要素の範囲がコード内容見るだけでわかるの最高。
これがわかるだけでも「足りてない情報無いか？」と不安にならずに済む。
また現役の管理者・運用者にも効果はある。
インフラに変更を加えないといけない時、まずはインフラ内容の把握などから始めると思うが、それがコード見るだけである程度わかってしまう。
時間短縮の恩恵を受けるのは現役の管理者・運用者も同じ。
また同じようなリソースを増やす場合は、同じコードを記載したりすることで楽に安全に対応することも可能。
効果3：インフラを再現しやすい + 簡単に捨てやすい
別の環境にすぐ同じインフラを建てたいという場合がある。
IaCで作ってるとコードをそのまま対象環境に持っていけば、同じインフラをすぐに建てれる。
ただ「再現したい」ってどんな状況やねんとは思うかもしれない。
例えば...
DR発生時にすぐに別環境で同じインフラを建てたいとか
インフラを様々な部署に配布する形態を取っているとか
実際、そこまで再現したい状況には遭遇しないっちゃしない。
簡単に捨てれるのもポイントが高い
「必要ない」「作り直したい！」となった時に、ゴミを残さず綺麗に捨てることが可能。
一部だけ「作り替えたいな！」となった時も、サッと捨てれる。
memo.iconインフラを分割してIaC管理しておくと、これがやりやすくなる。
効果4：バージョン管理を行うことができるようになり、監査対応などに利用できる
コードをバージョン管理すると、インフラの変更作業（追加・削除）の内容が全て残るため、監査で問われた時にも対応が可能になる。
また、現時点の構成がどうなってるかを問われた時も、コードの内容を見るだけで簡単に答えることができる。
変更を加えたインフラが障害を起こしたときに、前バージョンに切り戻すとかもできる。（バージョン管理してるおかげ）
効果5：CI/CDと組み合わせることで、インフラ変更のレビュー・自動テスト・デプロイが可能に
誰かが勝手にインフラの内容を変更するのを防ぎ、管理者が最終的な変更チェックを行なってからデプロイプロセスに乗せるなどが可能になる。
各環境に自動デプロイしたり、検証環境で自動テストしたりなどをインフラでもやる。
変更によるバグ・障害のリスクが小さくなり、システムの安定性が高くなる。
IaCのデメリット、逆効果
hr.icon
めっちゃ参考になる資料一覧（何回でも読み直すといい）
hr.icon
memo.icon
IaCがどう役立つかの仮説
環境ドリフトを防ぐ
管理者は1方の環境に手動で変更を加える場合、もう一方の環境にも同じように変更を加えなければならないが...
ミスや変更忘れによって、環境ドリフトが起こる。
環境ドリフトが起こると、その時点で脆弱なシステムを生み出すことになりうる。
開発環境ではうまくいったのに、本番環境ではうまくいかないなんてことが容易に起こりうる。そうなると、バグ・障害の回収で無駄な時間が発生することになる。
インフラ構成/環境の理解・調査にかかる時間を短縮する
手動構築よりは環境の再構築・再現が比較的容易（0から作り直そう！てなった時とか、環境を一気に掃除できたりする）
memo.iconそもそもインフラを再構築しないといけない場面にあまり遭遇しないんだが
バージョン管理することで、変更履歴を保存できる（監査とか、切り戻しとかで役立つ）
インフラをDevOpsワークフローに乗せることができる
インフラの監査機能も持てる（コードの内容がそのままインフラになってることから）
例えば、SSL暗号化をしてるかどうかをチェックできたりする
変更の際のインフラ構成/環境の把握に時間がかからない。また、ドキュメントと実際の内容が異なることもないので安心できる。
同じ環境を複数用意する必要があるときにミスせず用意できる
IaCに対する気持ち
IaCは長期的に稼働させることがわかってるシステムで使ってあげると有効。
長期の間で運用する人や管理する人は変わると思う。
その時にIaCで管理できてないと、手をつけにくくなる。つけるとしても時間がかかってしまって最終的に腐る。
逆に、1年、1ヶ月で終わるシステムとかなら、管理しなくてもいい。
運用者も変わらないだろうから、なおのことIaCでなくても問題ない場合もある。
環境ドリフトが嫌なら、使ってもいいが、短期間で終わるシステムなんて規模が知れてるし、そこまで変更が頻繁に起こるわけでもないだろう。となると、なおのことIaCは使うメリットが無くなる恐れある。
IaCへの苦労
コード内容と実環境の乖離が大きくなるとIaCの意味がなくなる。
その他の利点
信頼性、安全性、費用対効果を兼ね備えたシステムを構築できる
ガバナンス、セキュリティ、コンプライアンスの統制を可視化できる
障害のトラブルシューティングと解決のスピードを上げられる
インフラに変更を加える時の労力とリスクを抑えられる